導言

本書籍由劣質的程式碼一章引導出，劣質的程式碼會導致一家的倒閉，因此好的程式碼是有其必要的，但什麼是好的程式碼？

架構

二至六章介紹命名、函式、註解、物件，光是這些coding 時必用的工具，就是一門學問了。
第七章講錯誤處理
第八章講邊界
第九章講單元測試
第十章講類別
第十一章講系統
第十二章講羽化
第十三章講平行化
第十四章講持續地精練
第十五章講 JUnit 內容結構
第十六章講 SeriaData
第十七章講 程式碼的氣味和啟發

摘要

每個函式只有一層抽象概念
為了要確定我們的函式只有做「一件事情」,我們需要確定在函式裡的敘述都位在抽象概念的「同一層次」。
我們可以很容易看到 Listing 3–1 是如何違反這個準則的。
在裡面, 我們可以找到一些概念是位於抽象概念的高層次,如: 
getHtml()
有的是位於抽象概念的中層次,如: 
String pagePathName = PathParser.render (pagePath);
而剩下的則是在抽象概念的低層次,如:
.append(:\n")
一個函式擁有混合層次的抽象概念,總是令人困惑。讀者會無法分辨某個表達式 (expression)是一個基本概念還是一個細節。更糟糕的是,就像破窗效應一樣,一但將細節和本質概念混在一起,就會有越來越多的細節雜處於函式裡。
由上而下閱讀程式碼:降層準則
我們希望程式的閱讀就像是由上而下的敘事。我們希望每個函式後面都緊接著『下一層次的抽象概念」,如此,我們在閱讀程式時,可依照看到的一連串函式,對應著抽象層次降層閱讀。我稱這個方法為降層準則。
換句話說,我們希望在閱讀程式時,能夠像閱讀一連串 TO 段落,每個段落敘述著目前所處的抽象層次,並且提及了接續的下個層次的 TO 段落。
為了(To)要包含設定和拆解,我們先納入設定,再納入測試頁的內容, 最後納入拆解。
為了要納入這些設定值,如果是套件的話,我們會納入套件設定步驟, 然後再引入一般的設定步驟。
為了要納入套件設定,我們先搜尋「SuiteSetup」頁面的上層,然後加入納入該頁面路徑的敘述。

總結

難易度

⭐⭐⭐

自備技能

程式撰寫能力
架站經驗

適合對象

中階

心得

本書問世已經相當長一段時間，而本書所提之觀念也很影響現下的 coding 寫作，例如：編排：就有很多 lint 的套件在協助；至於：註解，則是幾乎都到 git comment 上了，不會去影響到 source code 的閱讀。
而現下流行的 microservice & FP ，籍由功能的拆分，讓各個系統做到低耦合，再將分派給各個工程師專司負責。
這其中一個好處，就是恰巧的將不可預測的因素降到最少，大型系統不會因為一個功能的出錯，而導致整個系統掛機。
而這樣的架構，也至少可以讓 bad coding experience 的工程師的 code 留在其負責範圍內，其他人不用去管他的 code ，而導致人和的問題，工作不是專注在問題跟架構，而是辦公室政治上，那也是很累人的事。